Frontend Micro-Frontend: Mestring av Module Federation-arkitektur

I dagens raskt utviklende landskap for webutvikling kan det å bygge og vedlikeholde storskala frontend-applikasjoner bli stadig mer komplekst. Tradisjonelle monolittiske arkitekturer fører ofte til utfordringer som oppblåst kode, trege byggetider og vanskeligheter med uavhengige distribusjoner. Micro-frontends tilbyr en løsning ved å bryte ned frontenden i mindre, mer håndterbare deler. Denne artikkelen dykker ned i Module Federation, en kraftig teknikk for å implementere micro-frontends, og utforsker dens fordeler, arkitektur og praktiske implementeringsstrategier.

Hva er Micro-Frontends?

Micro-frontends er en arkitektonisk stil der en frontend-applikasjon dekomponeres i mindre, uavhengige og distribuerbare enheter. Hver micro-frontend eies typisk av et separat team, noe som gir større autonomi og raskere utviklingssykluser. Denne tilnærmingen speiler microservices-arkitekturen som er vanlig på backend.

Nøkkelegenskaper ved micro-frontends inkluderer:

• Uavhengig distribusjon: Hver micro-frontend kan distribueres uavhengig uten å påvirke andre deler av applikasjonen.
• Teamautonomi: Ulike team kan eie og utvikle forskjellige micro-frontends ved hjelp av sine foretrukne teknologier og arbeidsflyter.
• Teknologisk mangfold: Micro-frontends kan bygges med forskjellige rammeverk og biblioteker, slik at teamene kan velge de beste verktøyene for jobben.
• Isolasjon: Micro-frontends bør være isolert fra hverandre for å forhindre kaskadefeil og sikre stabilitet.

Hvorfor bruke Micro-Frontends?

Å ta i bruk en micro-frontend-arkitektur gir flere betydelige fordeler, spesielt for store og komplekse applikasjoner:

• Forbedret skalerbarhet: Å bryte ned frontenden i mindre enheter gjør det lettere å skalere applikasjonen etter behov.
• Raskere utviklingssykluser: Uavhengige team kan jobbe parallelt, noe som fører til raskere utvikling og utgivelsessykluser.
• Økt teamautonomi: Teamene har mer kontroll over koden sin og kan ta beslutninger uavhengig.
• Enklere vedlikehold: Mindre kodebaser er lettere å vedlikeholde og feilsøke.
• Teknologiuavhengig: Teamene kan velge de beste teknologiene for sine spesifikke behov, noe som åpner for innovasjon og eksperimentering.
• Redusert risiko: Distribusjoner er mindre og hyppigere, noe som reduserer risikoen for storskala feil.

Introduksjon til Module Federation

Module Federation er en funksjon introdusert i Webpack 5 som lar JavaScript-applikasjoner dynamisk laste kode fra andre applikasjoner under kjøring. Dette muliggjør opprettelsen av virkelig uavhengige og sammensettbare micro-frontends. I stedet for å bygge alt inn i en enkelt pakke, lar Module Federation forskjellige applikasjoner dele og konsumere hverandres moduler som om de var lokale avhengigheter.

I motsetning til tradisjonelle tilnærminger til micro-frontends som er avhengige av iframes eller webkomponenter, gir Module Federation en mer sømløs og integrert opplevelse for brukeren. Det unngår ytelsesbelastningen og kompleksiteten knyttet til disse andre teknikkene.

Hvordan Module Federation fungerer

Module Federation opererer på konseptet med å "eksponere" og "konsumere" moduler. Én applikasjon ("verten" eller "containeren") kan eksponere moduler, mens andre applikasjoner ("fjernapplikasjonene" eller "remotes") kan konsumere disse eksponerte modulene. Her er en oversikt over prosessen:

1. Eksponering av modul: En micro-frontend, konfigurert som en "remote"-applikasjon i Webpack, eksponerer visse moduler (komponenter, funksjoner, verktøy) gjennom en konfigurasjonsfil. Denne konfigurasjonen spesifiserer modulene som skal deles og deres tilsvarende inngangspunkter.
2. Konsumering av modul: En annen micro-frontend, konfigurert som en "vert"- eller "container"-applikasjon, erklærer fjernapplikasjonen som en avhengighet. Den spesifiserer URL-en der fjernapplikasjonens Module Federation-manifest (en liten JSON-fil som beskriver de eksponerte modulene) kan finnes.
3. Oppløsning under kjøring: Når vertsapplikasjonen trenger å bruke en modul fra fjernapplikasjonen, henter den dynamisk fjernapplikasjonens Module Federation-manifest. Webpack løser deretter modulavhengigheten og laster den nødvendige koden fra fjernapplikasjonen under kjøring.
4. Kodedeling: Module Federation tillater også kodedeling mellom vert- og fjernapplikasjoner. Hvis begge applikasjonene bruker samme versjon av en delt avhengighet (f.eks. React, lodash), vil koden bli delt, noe som unngår duplisering og reduserer pakkestørrelser.

Sette opp Module Federation: Et praktisk eksempel

La oss illustrere Module Federation med et enkelt eksempel som involverer to micro-frontends: en "Produktkatalog" og en "Handlevogn". Produktkatalogen vil eksponere en produktlistekomponent, som Handlevognen vil konsumere for å vise relaterte produkter.

Prosjektstruktur

  
  micro-frontend-example/
    product-catalog/
      src/
        components/
          ProductList.jsx
        index.js
        webpack.config.js
    shopping-cart/
      src/
        components/
          RelatedProducts.jsx
        index.js
        webpack.config.js
  

Produktkatalog (Remote)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... andre webpack-konfigurasjoner
    plugins: [
      new ModuleFederationPlugin({
        name: 'product_catalog',
        filename: 'remoteEntry.js',
        exposes: {
          './ProductList': './src/components/ProductList',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Forklaring:

• name: Det unike navnet på fjernapplikasjonen.
• filename: Navnet på inngangspunktfilen som vil bli eksponert. Denne filen inneholder Module Federation-manifestet.
• exposes: Definerer hvilke moduler som vil bli eksponert av denne applikasjonen. I dette tilfellet eksponerer vi `ProductList`-komponenten fra `src/components/ProductList.jsx` under navnet `./ProductList`.
• shared: Spesifiserer avhengigheter som bør deles mellom vert- og fjernapplikasjoner. Dette er avgjørende for å unngå duplisert kode og sikre kompatibilitet. `singleton: true` sikrer at bare én instans av den delte avhengigheten lastes. `eager: true` laster den delte avhengigheten i utgangspunktet, noe som kan forbedre ytelsen. `requiredVersion` definerer det akseptable versjonsområdet for den delte avhengigheten.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

      {products.map((product) => (
        
{product.name} - ${product.price}
      ))}
    
  );

  export default ProductList;
  

Handlevogn (Host)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... andre webpack-konfigurasjoner
    plugins: [
      new ModuleFederationPlugin({
        name: 'shopping_cart',
        remotes: {
          product_catalog: 'product_catalog@http://localhost:3001/remoteEntry.js',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Forklaring:

• name: Det unike navnet på vertsapplikasjonen.
• remotes: Definerer fjernapplikasjonene som denne applikasjonen vil konsumere moduler fra. I dette tilfellet erklærer vi en fjernapplikasjon kalt `product_catalog` og spesifiserer URL-en der `remoteEntry.js`-filen kan finnes. Formatet er `remoteName: 'remoteName@remoteEntryUrl'`.
• shared: I likhet med fjernapplikasjonen definerer også vertsapplikasjonen sine delte avhengigheter. Dette sikrer at vert- og fjernapplikasjonene bruker kompatible versjoner av delte biblioteker.

src/components/RelatedProducts.jsx

  
  import React, { useEffect, useState } from 'react';
  import ProductList from 'product_catalog/ProductList';

  const RelatedProducts = () => {
    const [products, setProducts] = useState([]);

    useEffect(() => {
      // Hent data for relaterte produkter (f.eks. fra et API)
      const fetchProducts = async () => {
        // Erstatt med ditt faktiske API-endepunkt
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Relaterte produkter
        {products.length > 0 ?  : 
Laster...
}
      
    );
  };

  export default RelatedProducts;
  

Forklaring:

• import ProductList from 'product_catalog/ProductList'; Denne linjen importerer `ProductList`-komponenten fra `product_catalog`-fjernapplikasjonen. Syntaksen `remoteName/moduleName` forteller Webpack at den skal hente modulen fra den spesifiserte fjernapplikasjonen.
• Komponenten bruker deretter den importerte `ProductList`-komponenten for å vise relaterte produkter.

Kjøre eksempelet

1. Start både Produktkatalog- og Handlevogn-applikasjonene ved hjelp av deres respektive utviklingsservere (f.eks. `npm start`). Sørg for at de kjører på forskjellige porter (f.eks. Produktkatalog på port 3001 og Handlevogn på port 3000).
2. Naviger til Handlevogn-applikasjonen i nettleseren din.
3. Du skal se seksjonen for relaterte produkter, som blir gjengitt av `ProductList`-komponenten fra Produktkatalog-applikasjonen.

Avanserte konsepter i Module Federation

Utover det grunnleggende oppsettet tilbyr Module Federation flere avanserte funksjoner som kan forbedre din micro-frontend-arkitektur:

Kodedeling og versjonering

Som vist i eksemplet, tillater Module Federation kodedeling mellom vert- og fjernapplikasjoner. Dette oppnås gjennom `shared`-konfigurasjonsalternativet i Webpack. Ved å spesifisere delte avhengigheter kan du unngå duplisert kode og redusere pakkestørrelser. Riktig versjonering av delte avhengigheter er avgjørende for å sikre kompatibilitet og forhindre konflikter. Semantisk versjonering (SemVer) er en mye brukt standard for versjonering av programvare, som lar deg definere kompatible versjonsområder (f.eks. `^17.0.0` tillater enhver versjon større enn eller lik 17.0.0, men mindre enn 18.0.0).

Dynamiske remotes

I forrige eksempel var fjern-URL-en hardkodet i `webpack.config.js`-filen. Men i mange virkelige scenarier kan det være nødvendig å bestemme fjern-URL-en dynamisk under kjøring. Dette kan oppnås ved å bruke en promise-basert remote-konfigurasjon:

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Hent fjern-URL-en fra en konfigurasjonsfil eller et API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

Dette lar deg konfigurere fjern-URL-en basert på miljøet (f.eks. utvikling, staging, produksjon) eller andre faktorer.

Asynkron modullasting

Module Federation støtter asynkron modullasting, slik at du kan laste moduler ved behov. Dette kan forbedre den innledende lastetiden for applikasjonen din ved å utsette lasting av ikke-kritiske moduler.

  
  // RelatedProducts.jsx
  import React, { Suspense, lazy } from 'react';

  const ProductList = lazy(() => import('product_catalog/ProductList'));

  const RelatedProducts = () => {
    return (
      

        
Relaterte produkter
        Laster...
}>
          
        
      
    );
  };
  

Ved å bruke `React.lazy` og `Suspense` kan du asynkront laste `ProductList`-komponenten fra fjernapplikasjonen. `Suspense`-komponenten gir et reserve-UI (f.eks. en lasteindikator) mens modulen lastes.

Fødererte stiler og ressurser

Module Federation kan også brukes til å dele stiler og ressurser (assets) mellom micro-frontends. Dette kan bidra til å opprettholde et konsistent utseende og følelse på tvers av applikasjonen din.

For å dele stiler kan du eksponere CSS-moduler eller styled-components fra en fjernapplikasjon. For å dele ressurser (f.eks. bilder, fonter), kan du konfigurere Webpack til å kopiere ressursene til en delt plassering og deretter referere til dem fra vertsapplikasjonen.

Beste praksis for Module Federation

Når du implementerer Module Federation, er det viktig å følge beste praksis for å sikre en vellykket og vedlikeholdbar arkitektur:

• Definer klare grenser: Definer tydelig grensene mellom micro-frontends for å unngå tett kobling og sikre uavhengig distribusjon.
• Etabler kommunikasjonsprotokoller: Definer klare kommunikasjonsprotokoller mellom micro-frontends. Vurder å bruke hendelsesbusser, delte state management-biblioteker eller tilpassede API-er.
• Håndter delte avhengigheter nøye: Håndter delte avhengigheter nøye for å unngå versjonskonflikter og sikre kompatibilitet. Bruk semantisk versjonering og vurder å bruke et verktøy for avhengighetsstyring som npm eller yarn.
• Implementer robust feilhåndtering: Implementer robust feilhåndtering for å forhindre kaskadefeil og sikre stabiliteten til applikasjonen din.
• Overvåk ytelse: Overvåk ytelsen til dine micro-frontends for å identifisere flaskehalser og optimalisere ytelsen.
• Automatiser distribusjoner: Automatiser distribusjonsprosessen for å sikre konsistente og pålitelige distribusjoner.
• Bruk en konsistent kodestil: Håndhev en konsistent kodestil på tvers av alle micro-frontends for å forbedre lesbarhet og vedlikeholdbarhet. Verktøy som ESLint og Prettier kan hjelpe med dette.
• Dokumenter arkitekturen din: Dokumenter din micro-frontend-arkitektur for å sikre at alle teammedlemmer forstår systemet og hvordan det fungerer.

Module Federation vs. andre Micro-Frontend-tilnærminger

Selv om Module Federation er en kraftig teknikk for å implementere micro-frontends, er det ikke den eneste tilnærmingen. Andre populære metoder inkluderer:

• Iframes: Iframes gir sterk isolasjon mellom micro-frontends, men de kan være vanskelige å integrere sømløst og kan ha en ytelsesbelastning.
• Web Components: Webkomponenter lar deg lage gjenbrukbare UI-elementer som kan brukes på tvers av forskjellige micro-frontends. Imidlertid kan de være mer komplekse å implementere enn Module Federation.
• Integrasjon ved byggetid: Denne tilnærmingen innebærer å bygge alle micro-frontends inn i en enkelt applikasjon ved byggetid. Selv om det kan forenkle distribusjon, reduserer det teamautonomi og øker risikoen for konflikter.
• Single-SPA: Single-SPA er et rammeverk som lar deg kombinere flere single-page-applikasjoner til én enkelt applikasjon. Det gir en mer fleksibel tilnærming enn integrasjon ved byggetid, men kan være mer komplekst å sette opp.

Valget av hvilken tilnærming man skal bruke avhenger av de spesifikke kravene til applikasjonen din og størrelsen og strukturen på teamet ditt. Module Federation tilbyr en god balanse mellom fleksibilitet, ytelse og brukervennlighet, noe som gjør det til et populært valg for mange prosjekter.

Eksempler på Module Federation fra den virkelige verden

Selv om spesifikke bedriftsimplementeringer ofte er konfidensielle, blir de generelle prinsippene for Module Federation brukt i ulike bransjer og scenarier. Her er noen potensielle eksempler:

• E-handelsplattformer: En e-handelsplattform kan bruke Module Federation til å skille forskjellige deler av nettstedet, som produktkatalogen, handlekurven, utsjekkingsprosessen og brukerkontoadministrasjon, i separate micro-frontends. Dette lar forskjellige team jobbe med disse seksjonene uavhengig og distribuere oppdateringer uten å påvirke resten av plattformen. For eksempel kan et team i *Tyskland* fokusere på produktkatalogen mens et team i *India* administrerer handlekurven.
• Finansielle tjenesteapplikasjoner: En finansiell tjenesteapplikasjon kan bruke Module Federation for å isolere sensitive funksjoner, som handelsplattformer og kontoadministrasjon, i separate micro-frontends. Dette øker sikkerheten og muliggjør uavhengig revisjon av disse kritiske komponentene. Se for deg et team i *London* som spesialiserer seg på funksjoner for handelsplattformen og et annet team i *New York* som håndterer kontoadministrasjon.
• Innholdsstyringssystemer (CMS): Et CMS kan bruke Module Federation for å la utviklere lage og distribuere tilpassede moduler som micro-frontends. Dette gir større fleksibilitet og tilpasning for brukere av CMS-et. Et team i *Japan* kan bygge en spesialisert bildegallerimodul, mens et team i *Brasil* lager en avansert tekstredigerer.
• Helseapplikasjoner: En helseapplikasjon kan bruke Module Federation til å integrere forskjellige systemer, som elektroniske pasientjournaler (EPJ), pasientportaler og faktureringssystemer, som separate micro-frontends. Dette forbedrer interoperabilitet og gjør det enklere å integrere nye systemer. For eksempel kan et team i *Canada* integrere en ny telehelse-modul, mens et team i *Australia* fokuserer på å forbedre pasientportal-opplevelsen.

Konklusjon

Module Federation gir en kraftig og fleksibel tilnærming til implementering av micro-frontends. Ved å la applikasjoner dynamisk laste kode fra hverandre under kjøring, muliggjør det opprettelsen av virkelig uavhengige og sammensettbare frontend-arkitekturer. Selv om det krever nøye planlegging og implementering, gjør fordelene med økt skalerbarhet, raskere utviklingssykluser og større teamautonomi det til et overbevisende valg for store og komplekse webapplikasjoner. Ettersom landskapet for webutvikling fortsetter å utvikle seg, er Module Federation posisjonert til å spille en stadig viktigere rolle i å forme fremtiden for frontend-arkitektur.

Ved å forstå konseptene og beste praksis som er skissert i denne artikkelen, kan du utnytte Module Federation til å bygge skalerbare, vedlikeholdbare og innovative frontend-applikasjoner som møter kravene i dagens raske digitale verden.